Ian & Stuart's Australian Mac: Not for Sale/Another.not.for.sale (Australia).iso/fade into you/being there/Services/Gopher/3Dgopherspace

Text File | 1994-05-01 | 36KB | 821 lines

A Preliminary Design for a 3-D Spatial

User Interface for Internet Gopher


Mark P. McCahill

Distributed Computing Systems & Services

University of Minnesota


Thomas Erickson

User Experience Architect’s Office

Apple Computer




Introduction


Internet Gopher is an information system used to publish and
organize information on servers distributed across the Internet.
Since its introduction in June, 1991 Gopher has become quite
popular. In December 1993, there were over 4800 gopher servers
accessible on the Internet, and well over 1.5 million items
accessible in gopherspace. By March 1994 there were 6700 gopher
servers accessible over the Internet. Gopher traffic across the
NSFnet backbone has been increasing at an average rate of 20% a
month during the last year, and Gopher’s share of the total NSFnet
traffic has increased to about 3.5%. Because Gopher is a very
distributed system, it is difficult to estimate the number of
Gopher users. However, comparing Gopher’s portion of the NSFnet
traffic to other popular protocols is a way to get a rough feel
for Gopher’s popularity. Over the NSFnet, ftp makes up around 40%
of the traffic, Netnews 10%, SMTP e-mail 6.7%, telnet 5.7%, and
Gopher 3.5%. There are now at least 4 different Macintosh Gopher
clients, 5 Windows clients, four clients for Unix/X-windows, two
Amiga clients, a VMS client, and even Gopher clients for MVS and
VM/CMS. All these clients have conceptually similar user
interfaces.


The typical gopher client present users with a directory hierarchy
to navigate. Each gopher directory the user encounters may contain
documents, search engines and other directories. The items in the
gopher directory have both a content type associated with them and
a name to be displayed to the user. Gopher clients traditionally
display different icons for the various items and list the item
names next to the icons while while using the name of the
directory as a title of the window containing the directory. Some
clients restrict the user to viewing each successive directory in
a single window, while other clients allow for multiple windows
(each successive directory is displayed in a new window). Gopher
clients provide no representation of a Gopher Server as a whole
(such as a diagram of the hierarchy); servers are represented
simply as the root directory in a hierarchy.


The aim of this paper is to sketch out a design for a new, 3-D
space user interface for Gopher, and to capture some of the
rationale behind the design. The design is motivated by a mix of
pragmatic and exploratory impulses. On the one hand, there are
several usage problems that would be difficult to solve within the
constraints of the current interface metaphor. And, on the other
hand, the advent of RISC-based personal computers means that there
will be sufficient power to support a whole range of new
behaviors, offering the prospect of transforming information
systems into more flexible, information-rich environments. We will
begin with a brief discussion of the motivating factors, and will
then describe the initial design; comments on the design rationale
will be inserted where appropriate.


Problems and Prospects


While the current user interface is popular, there are a number of
well known usage problems:


•    The lost-in-space problem. Users complain of feeling lost after
navigating for a while and have difficulty remembering where
they found an interesting item. In part, this due to the absence
of any global representation of the structure of information
hierarchy, and in part because the path followed by a user is
either invisible or, at best, implicitly embodied in a stack of
directory windows laid on top of one another. Users need an
overview of gopherspace, within which they can see their
locations and the paths they have followed.


•    The grouping problem. Within a directory it is difficult to show
relationships between items represented in a linear list. Some
server administrators resort to putting items with blank names
in their directories to group clusters of items. An analog of
this problem occurs in lists of results generated by search
engines. The results are typically sorted by relevance (as
ranked by the search engine), but the user interface doesn’t
have a good way to convey their relative relevance. And, as in
directories, it is difficult to show the clustering of related
sets of documents. Ideally, both relevance to the search terms
and “closeness” to other documents (along a variety of user-
specifiable dimensions) ought to be visible to the user at a
glance.


•    The browsing problem. It is difficult to browse because
documents reflect so little of their content. All that is
available is the item’s name and the information about the
document’s type embodied in the icon.The user’s only other
option is to open the document—often a time consuming
process—and see everything in the document. Neither option is
supportive of browsing: users need to see more information about
the content of a document without there being so much that they
are unable to compare and contrast different documents. Such
document representations will be referred to as proxies.


In addition to remedying today’s usage problems, there are a
number of intriguing prospects which a new interface could open to
exploration:


•    Leveraging social intelligence. Users browsing a large
information space could benefit from the discoveries of previous
visitors. Indications of the popularity, utility, or quality of
particular documents, directories, or servers could be useful.
Sometimes this information could be generated automatically by
the client in response to user activity; or it might be
interesting to allow users to attach comments and critiques to
documents. Similarly, users with expertise in particular areas
might create, define, and annotate documents relevant to a
particular theme.


•    Sense of place. Today, gopherspace is generic: any gopher
directory looks just like all the others, regardless of where it
is or what it contains. Providing a sense of place means moving
from the generic to the particular, making it possible for an
area of gopherspace to reflect something of its contents, and
something about those who construct it, maintain it, and
frequent it. The ability to provide a sense of place would have
benefits for both administrators and users. It would provide a
way for administrators to put their own personal stamp on their
segment of gopherspace. Server administrators would like to be
able to customize their areas, but, needless to say, given the
constraints of a linear list of names and icons, opportunities
for doing this are quite limited. Supporting customization by
administrators is important because many Gopher servers are
maintained by volunteers with little or no institutional support
or recognition; anything which can increase the gratification
administrators receive from their efforts will ultimately
benefit gopherspace as a whole. Users too would benefit from a
sense of place, in part because it is entwined with the ability
to leverage social intelligence. In addition, providing such
collectively generated traces enhances the sense of place, and
transforms Gopherspace from something ‘owned’ primarily by
server administrators to a more public, collectively shaped sort
of space. Given these capabilities, it is natural that some
places will evolve into navigational landmarks.


•    Information-rich environments that support human-human
interaction. Turning to a data space for information is often a
last resort; in many cases, people prefer to get information
from other people. In fact, sometimes people search for
documents, only as pointers to their authors. In a very real
sense, a comprehensive data space will include people, not just
documents. In a similar vein, although information access may be
engaged in just for the fun of it, it is more often the means to
some larger end. That is, people seek information because they
are trying to solve a problem, test a theory, understand a
concept, or communicate their understanding to others. In these
cases, there is little reason to segregate information access
from the other activities. The increasing computational power
and bandwidth that is now available offer the prospect of moving
from information-only spaces to information-rich environments
which can support a broad range of activities.



Initial Design Criteria


The problems and prospects we have just covered map fairly cleanly
into a few general design criteria.


•    Richer representations for servers, directories, and documents.
The lost-in-space problem suggests the need for a high level
overview of gopherspace and landmarks. The grouping problem
indicates the need for a representation of collections of
documents that can represent their similarities and differences
along a variety of dimensions; we shall refer to such
representations as neighborhoods. Similarly, the use of proxies
— richer representations for individual documents — would
alleviate the browsing problem.


•    Dynamic representations. Representations need to be able to
change over time. Sense of place requires representations that
can be customized by administrators and perhaps end users, and
leveraging social intelligence requires representations able to
reflect the interaction history of individual documents and
collections of documents.


•    Need for availability and addition of meta-information. All of
these changes to the representations of components of
Gopherspace require that meta-information about servers,
directories, and documents be made available via the Gopher
protocol. The prospects of providing a sense of place, and
leveraging social intelligence, also involve adding meta-
information, but this time the meta-information is external to
gopherspace — it is applied by users, or inferred by the system
based on user interaction. Finally, meta-information will be
required to support interactions among users.


•    Backward compatibility. There is a final, very important,
criterion not suggested by the preceding discussion. It is
important to recognize that there is a large installed base of
Gopher servers and clients, and a community of administrators
and end users—Gopher is as much a social phenomenon as a
technology. Backward compatibility of any new client is
essential for acceptance. It will be impossible to change all of
gopherspace overnight, so any new client must handle both
servers that have stored additional information (e.g., about
relative clustering of items in document collections) and
ancient unmodified servers. This must be done without stepping
outside the new user interface metaphor. Client software that
can synthesize the spatial scene from current gopher directory
and item meta-information allows us maintain compatibility with
all of the current gopher servers. A happy side effect of this
approach is that server and network bandwidth demands are
minimized since we do not require servers to render scenes and
ship bitmaps of the scenes over the network. Backward
compatibility issues are also addressed by using the Gopher+
protocol’s item attributes to hold meta-information. Gopher+
item attributes provide an open-ended, extensible way of
associating arbitrary meta-information with items and
directories, and methods of accepting information sent from the
client, so the user interface we propose will not require a new
protocol.




Why a 3-D spatial interface?


First, note that 3-D space as a metaphor for information is
nothing new; it is deeply embedded in our language. Without
thinking about it, people use spatial and object-centered terms
for discussing abstract concepts. We speak of getting overviews,
seeing things from different perspectives, and grasping new ideas.
Providing a 3-D spatial interface is, in part, just providing a
concrete embodiment of language we already use.


A 3-D spatial user interface for Gopher also allows us to address
the problems and prospects we’ve just discussed. 3-D spaces give
us more variables with which to construct the richer
representations we need. For example, relationships between
documents — either manually defined by server administrators or
automatically generated by search engines returning a set of hits
to a query — can be shown by various arrangements of document
icons in a space. 3-D spaces can also give the user a stronger
sense of place and minimize the feeling of being lost. If there
are enough provisions for server administrators to customize the
attributes of the space, a better defined sense of place will
evolve and users will treat some collections of items as landmarks
in gopherspace.Variables that server administrators can customize
should include a texture (bitmap) which is painted onto the
surface of 3-D icons and the relative position of 3-D icons.
Another very valuable property of 3-D representations is that they
implicitly include two representations: a surround view when you
are "in" the 3-D space (suitable for viewing collections of
documents), and a bird's eye view when you are "above" the 3-D
space (suitable from providing the overview). The fact that the
same conceptual model provides two different representations which
are connected in a well understood way (and, in fact, which permit
the transition from one to another to be shown) is very powerful.


Another advantage of 3-D space is that it is familiar; people
understand a lot about space. They are familiar with navigating
space since this is something they do everyday of their lives to
get from one place to another, and to manipulate objects and
tools. Since people have little experience flying through space,
we intend to implement constrained navigation, so that the user
experience is something like driving a car. People also know that
finding things in a space is not particularly easy (thus, we may
be able to avoid raising expectations too high), and have a
learned repertoire of techniques for finding things (consulting
maps, following paths, asking a passerby) that can be embedded in
the metaphor.


Finally, when we are ready to put real-time IRC/talk capabilities
into gopherspace, 3-D spaces provide a natural way of supporting
interaction between people. As human beings, we understand a lot
about the social characteristics of spaces.We understand the
distinction between public and private spaces; we know that you
have to pay to enter some spaces at which time you gain temporary
rights to that space. We understand that particular activities,
people, rituals, and behaviors are associated with particular
types of spaces. We have spent out lives learning to recognize
spatial cues: what entrances look like, what a bulletin board is,
where you are likely to find a you-are-here map, and so on. All
this knowledge can be leveraged in a spatial metaphor.


Besides, it’ll be loads of fun.

The Preliminary Design


In this section we sketch out the preliminary design for the
interface, with some comments on the rationale for various
decisions.  It is important to emphasize that this is the starting
point, not the ending point. In general, the preliminary design is
based on a combination of analysis and intuition; at this point,
no testing or prototyping has been done, with the exception of a
few mock-ups of 3-D icons and neighborhoods generated to
facilitate discussion of how to design legible 3-D icons, and how
to support navigation among them. We take it as a certainty that
as we proceed both implementation constraints and feedback from
prospective users will shape the design in major and unforeseen
ways.


For expository purposes we will describe the preliminary design in
terms of three levels of representation —  the overview, the
neighborhood, and the individual item. We will begin with the
neighborhood, the representation for a collection of items with
which the user is interacting. Next we will examine some details
of the 3-D icons used to represent individual items.  Finally,
we’ll look at the representations which provide the overview of a
particular server, and of gopherspace as a whole. In describing
how users might interact with these representations, we will
mostly focus on near future scenarios in which Gopherspace is
still primarily used as an information system, with occasional
allusions to farther out possibilities.


The Neighborhood

The neighborhood is the representation of the collection of items
with which the user is interacting. Neighborhoods are either
constructed by server administrators (as a directory in the the
server’s file hierarchy) or generated by search engines in
response to a user-entered query.




Figure 1: the circular  “Stonehenge“  icon arrangement.


The Arrangement of the Icons

We explored two representations of neighborhoods: circles and
‘streets’. Circular arrangements of items have a number of
strengths.  First, the  user will generally have a straight on
view of the fronts of a couple of 3-D icons, which is valuable
because the fronts of these icons will generally contain details
of their content. Since the user enters the neighborhood near the
center of the circle of icons, the user is always going to be
looking at something and it is difficult to drive off into limbo.
A second useful property of a circular arrangement is that it is
easy for the user to understand: the user can quickly get an idea
of how many icons are in the neighborhood (based on the density of
icons and the radius of the circle). The circular arrangement of
icons defines an enclosed space that may be used as a collective
gathering space for users. The circular arrangement also defines a
center point, at which we will place a 3-D ‘kiosk’ icon that will
function as the user’s link back to the previous neighborhood, and
as a sort of information desk for the neighborhood. If we allow
for display of user-entered comments from the people who have
visited this directory (i.e. graffiti) this should also appear on
the kiosk. The street metaphor was investigated and rejected
because the user is either facing down the axis of the street and
has an oblique view of most of the faces of the icons, or is
facing one side of the street and is required to turn fully around
to view the next closest icon. It also may be difficult for users
to tell how long a street is, and unless the street is short, it
really has no center or natural gathering point. Finally, simple
mock-ups of streets in a 3-D modeling program resulted in
arrangements that felt very claustrophobic, since fairly large 3-D
icons were necessary for information display purposes.


A variant of the circular arrangement of items is the spiral.We
intend to use the spiral arrangement for collections of icons
generated by search engines in response to user queries. Formally,
the spiral has a nice family resemblance to the circular
arrangement so that it too defines an enclosed area with a center
point; at the same time, its greater openness and dynamicism seems
a good reflection of the transitory nature of most queries. Also,
a spiral has directionality, and thus provides a natural ordering
within which the relevance of items to the query can be reflected.
That is, the more relevant the items, the closer they are to the
root of the query; and, more generally, a search that returns a
large number of very relevant items will have a tightly coiled
spiral, whereas one with few relevant items will have a very loose
spiral.




figure 2: results of a search arranged in spiral fashion.



Sound

We intend to support the use of sound as a representation for a
neighborhood. Sound is valuable because it can maintain the sense
of being in a particular place, even when the place is too big or
complex to be shown all at once. Server administrators should be
able to define a digitized sound for sound-savvy clients to play
while the user is within the directory... hopefully unobtrusive
sounds similar to some of Brian Eno’s ambient music. Sound can
play a variety of other roles. It may be used to reflect activity
of other users in the same or nearby neighborhoods. Variations in
its timbre could be used to give hints as to the size of the
neighborhood. Sounds could also be used as part of the proxy of an
item, perhaps brought into play when a user comes near the icon: a
directory’s proxy might use sound to give a hint of what the new
neighborhood is like before the user enters it; a document’s proxy
might use whispered text-to-speech to provide more detail about a
document’s content.To make sound a common part of all 3-D space
will require synthesizing sounds for gopher servers that do not
provide a server-defined sound. Having the client software
generate an ambient wind sound attenuated by the number (and type)
of objects in the scene is probably the best approach creating
sounds for servers that do not have their own. By making the
attenuation of the ambient wind sound depend on the objects in the
local space we can get automatically create variation in tone and
timbre.


Wear

If usage information is available from the server, footprints (or
some sort of dirt on the ground) can be used to show which of the
items in the neighborhood are the most popular.This is like the
worn marks on subway platforms in New York. You can predict where
the doors of the subway train will be when it stops by looking at
the worn spots on the platform. The same sort of cue can be used
in a neighborhood to show users who want to follow the beaten
path, where that path lies.



The 3-D Icons

3-D icons vary along four dimensions: their form, their color,
their texture, and the information about their content displayed
on their fronts (this information is called a proxy). The basic
form of a 3-D icon is a rectangular box with a top that represents
the type of the object. Box-like icons are attractive since they
keep the scene rendering requirements to a minimum by keeping the
number of polygons down and simplifying hidden surface removal.
Box-like objects also provide plenty of space to map textures,
draw items names and other information, and can look vaguely like
buildings people encounter in life.


The Forms of 3-D Icons

The general form of the icon indicates the type of object it
represents: the constraints on the icons’ forms are that the
icon’s type should be recognizable from any direction (and ideally
from a distance), that most icons have a large, flat surface area
on which its proxy may be displayed, and that the form be
relatively simple so that large directories displayed by clients
on low-end machines not take excessively long to render.  Figures
3 through 8 show initial passes on the forms for types of icons
thus far envisioned.




Figure 3:Document icon.    Figure 4. Neighborhood icon    Figure
5.Search engine icon




Figure 6:interactive session icon    Figure 7: Person
icon    Figure 8. Kiosk icon




Color of 3-D Icons

At the moment our intent is to use color as redundant information,
to indicate the type of the icon. The advantage of this is that it
will allow types to be distinguished in overviews.


Dynamic Proxies

The face of the 3-D icon is divided into areas used for the name
of the item and the proxy. The title of the item is written across
the top: on document icons there is a ridge wrapped around the
icon about 80% of the way up the icon where the title is written;
other icons have the title in the same location but without the
ridge. Below the title is where the proxy is displayed. The proxy
reflects something of the content of the object represented for
the icon: for a picture, it might contain a thumb-nail sketch; for
a text document it might contain key words; for a new
neighborhood, it might contain an indication of the neighborhood’s
size. On a layer underneath the proxy, and over all the rest of
the 3-D icon, a server-defined texture map is displayed


As the user approaches a 3-D icon, the amount of information
displayed on the icon changes since there is more screen real
estate to use for display and the user is presumably more
interested in the item. From a long distance, only the general
outline and color of the icon is readily discernible. At middle
distance the texture map and name of the icon are visible. At
close range, some proxies for the information within the icon
become visible. What the proxies are will vary depending on the
type of object. Directory icons may show a rough rendering of the
content of the directory (i.e. the number and arrangement of the
icons contained in that directory). Document proxies are probably
the first part of the document or a diskette icon to show that the
contents is a binary file. The document proxy referring to a
Quicktime video might contain the poster view of the video, while
a sound proxy might by an ear icon (or perhaps the sound plays at
low volume?) When the user puts the mouse pointer over an item it
may also develop a door or door knocker. Double clicking opens the
item. Opening a document could result in a new window being
displayed on the screen with the document contents inside.
Alternatively the content of the 3-D icon for a document could be
displayed on its face. Opening a directory results in a transition
to a new directory (see the transition between directories section
below



Representing Overviews of Gopherspace

We have not yet completely resolved how to represent overviews of
sections of gopherspace larger than a neighborhood so the design
in this section is very preliminary. However, such overviews are a
valuable addition to the user interface; there are two sorts of
overviews that users would like to have while navigating
gopherspace. First, a map of items on the current server or items
within a few hops of the current neighborhood (i.e. a regional
overview) is appealing since this would help users understand what
sort of neighborhood they are inside. This sort of local overview
would also be useful as a proxy to be displayed for the
neighborhood.


The other sort of overview that users would like is map of large
portions (or  all) of gopherspace.

Because Gopher is a distributed system without a compulsory server
registration, there is no global list of all servers in
gopherspace. In fact, maintaining such a list is a daunting
prospect given the growth in number of gopher servers (3400 in
September 1993, 4800 in December 1993, 6700 in March 1994).
However, a map of the neighborhoods that the user has visited is
feasible since the Gopher client software can build the map
dynamically as the user explores new neighborhoods. Alternatively,
some users may wish to download maps of Gopherspace, or portions
thereof, from a global map server.



Representing a Neighborhood’s region

To represent a region, the client software explores the in
vicinity of the current neighborhood by opening Gopher
neighborhoods connected to the current neighborhood to some
predefined depth (perhaps 3 hops). Once the client software has
queried Gopher servers to build up an internal list of
neighborhood contents in the region, an overview can be displayed
to the user.


One possibility for representation of the region around a
neighborhood is to use PARC cone trees.

Another possibility is to use 2-D projections of gopher hierarchy;
the circular “Stonehenge” neighborhood have a nice, legible
circular projection as do the spiral neighborhoods which result
from queries. Such an overview could look like figure 9.




Figure 9: 2-d projected Overview



Representing large parts of Gopherspace

While 2-d projections of neighborhoods can be generated for a
static region, representing a dynamically growing space using a
Euclidian plane is problematic if users expect the neighborhood to
stay in the same location and relative spatial relation to each
other. The problem is that the layout of the overview changes and
grows as the user explores gopherspace, and there may not be room
to display a new neighborhood without moving the projections of
neighborhoods already displayed (figure 10).





Figure 10: Before and after exploring reference to neighborhood D


To avoid this problem, either a non-Euclidean space or a different
approach used (such as PARC cone trees). A non-Euclidean space
would be something like a rubber sheet with neighborhoods acting
like rocks on the sheet. The sheet would be stretched as new
neighborhoods were added close to existing neighborhoods; how
successful such a metaphor would be with users is open to
conjecture.



Navigating Gopherspace


Navigating within a neighborhood

Most people are familiar with navigating 3-D spaces since this is
something they do everyday of their lives to get from one place to
another. On the other hand, most people have little experience
flying through space, so by limiting the number of options the
user has for flying into limbo, we can make the user experience
similar to some of the better arcade style games (like Spectre).
By limiting the user’s navigational controls to forward and back
turn left, turn right we can make it easy to learn how to use the
interface. By limiting the height of the 3-D icons, we can ensure
that the icon’s proxy will usually fit within the user’s field of
view, and thus we needn’t worry about providing ways to look up or
down, or left or right.



Transition between neighborhoods

When the user double-clicks on a 3-D icon representing another
neighborhood, a bit of user interface sugar should be used to make
it clear to the user they are traveling somewhere else... a rough
equivalent of the zoomrect transition used on the Macintosh when
an icon is opened. This is applied to directories, to search
engines, and when the user double clicks on the central kiosk of a
directory. If we handle this properly, it can also give the user
something to look at while the client software sets up and renders
the next neighborhood the user will view.


For the neighborhood-to-neighborhood transition, the user
automatically is sent on an trajectory leading them out of the
current neighborhood and into the new neighborhood (show in figure
11).

The trajectory starts with the user flying into the 3-D icon
representing the neighborhood, then ‘flying’ over a grid. Flying
here is flying in the sense of riding in an airplane as opposed to
actively piloting a plane.





figure 11: trajectory between directories


The amount of time spent in flight depends on how long the
software needs to fetch the information from the appropriate
gopher server and render the next neighborhood. Once the next
neighborhood is ready to be displayed to the user the flight over
the grid ends with an approach over (and then down into) the new
neighborhood. The user can get an idea of the general layout of
the neighborhood during the approach and landing.


The idea behind this trajectory is to give the user an increasing
sensation of motion as they leave the immediate vicinity of the
neighborhood they were in (take-off in a plane rising up from the
current neighborhood), followed by a few seconds of apparent high-
speed travel travel over an anonymous looking grid, culminating
with a slow approach to the new neighborhood. It is important that
the approach to the new neighborhood allows the user see the
general arrangement of the neighborhood. To make this visible, the
user’s trajectory is one of swooping down from above (like a plane
landing). The user is deposited near the central kiosk facing so
that both a part of the kiosk and some of the items in the
neighborhood are visible (figure 12).




figure 12: initial view on entering a new directory



Next Steps


By default, the Gopher client generates the geometry and layout of
the neighborhood within the user’s computer, but it is important
to allow server administrators some control over how clients
display the neighborhood. The sorts of controls a server
administrator could have are: layout within the neighborhood,
sound, textures mapped onto icons, wear (usage information), and
icon geometry. For an initial implementation, we plan to allow
server administrators to define texture attributes for Gopher
items (as a Gopher+ item attribute). Textures (bitmaps) are easy
to generate and carry a lot of information; most server
administrators do not have 3-D geometry design tools. Eventually
we would like to allow mapping Quicktime or MPEG video onto the
icons for a real Las Vegas-style user experience.


Eventually the intention is to allow server administrators to
design their own 3-D icons by defining the icon geometry for the
client, but there are serious potential problems with ornate
designs that take to much processing power to render in an
acceptable time. Once server administrators can create their own
icons, clients must take steps to protect themselves from badly
designed icons. Since the client has no assurance the server
administrator has done consistency checking, the clients would
have to employ local zoning restrictions by refusing to render
icons with excessive numbers of polygons (or non-convex polyhedra,
or other items beyond the limits of the client’s 3-D rendering
engine).


Another issue that arises once server administrators can design
their own icons is maintaining some sort of consistency for the
user so that they are not confronted with neighborhoods where
everything they know is wrong. When server administrators can
design their own 3-D icons, we will strongly advocate that the
tops of the icons remain the same throughout gopherspace. This
will allow users to assume that if the icon has a slanted top, is
is a search engine. Also, the basic box shape will probably be
strongly mandated since clients software expects to be able to map
textures and names onto the surface of the icons.


Rather than try to implement customized icons initially, we think
it is much more valuable to implement sound playback in the
clients. Again, like textures, there are a variety of tool for
creating and manipulating sound and it is easy for a server
administrator to associate a Gopher+ item attribute containing a
reference to a sound with an item or a neighborhood.


Textures and sounds are very high priorities for implementation,
but once these have been implemented, it makes sense to allow the
server administrator some control over the layout of the icons in
the neighborhood. This again requires clients to employ their own
local zoning ordinances to check the reasonableness of the layout
(disallowing overlapping polyhedra, for instance). The server
administrator would define relative locations of items within the
neighborhood as a Gopher+ item attribute.



Conclusions


As this is a report of work in progress, we have no real
conclusions, as yet.


It is worth noting that even in these earliest stages of design,
we have had to deal with issues that lie outside the realm of the
disciplines traditionally involved in interface design.  What
forms should 3-D icons have so that they are both simple and yet
recognizable from many directions.  What types of spatial layouts
can help people remain oriented in a large space?  What sort of
layouts are legible both from the inside and from far away?  How
rapidly should a transition into a new spatial layout occur, so
that the user can take in enough information to be oriented, but
avoid boredom?



Acknowledgements


This paper is based on dreams and discussions that have been going
on within part of the Gopher software development team (Paul
Lindner, Farhad Anklesaria, David Johnson, Neophytos Iacovou) at
the University of Minnesota over the last two years. We have also
learned from the work on YORB, carried out by Dan O’Sullivan and
his colleagues in the New York University School of Interactive
Telecommunications.



References


Bush, V.  As We May Think.


Hill, et al. & Wroblewski, et. al. on soft-wear.